前言

去年曾參加過一次鐵人賽，過程雖然蠻痛苦的，但也因為逼著自己每天寫文章，意外學會了不少東西，今年決定再來挑戰一次，希望這次也能有所收穫，順便看看自己能不能再突破一次，那下面我們就開始吧！

最近只要開始研究 AI Agent，就很容易看到一個名字：

MCP（Model Context Protocol）

現在很多 AI 工具都開始支援 MCP，但第一次接觸 MCP 時，我其實一直有個疑問：

AI 不是本來就可以呼叫 API、使用 Tool 了嗎？

那為什麼還需要 MCP？

接下來我們會來介紹以及解決這些疑問

AI 看不到你的世界

想像一下你在詢問 ChatGPT。

你問：

「幫我解釋什麼是 Docker。」

AI 可以直接回答，因為這是它本身已經知道的知識。

但如果你問：

「幫我看看我電腦上的 project 資料夾裡有哪些檔案。」

這時候 AI 就沒辦法直接回答了，因為它看不到你的電腦，因此就需要一些外部工具來幫助我們完成這件事。

例如：

AI
 │
 ├── File System
 ├── Database
 ├── Git
 ├── REST API
 └── Search

AI 負責「想」。

Tool 負責「做」。

Tool 越來越多

但這麼做就會有個問題，假設我們希望 AI 可以：

• 讀檔案
• 查 SQLite
• 操作 Git
• 呼叫 REST API
• 搜尋資料
• 發送 Email

最直接的方法，就是一個一個整合，但這樣每個 AI 都要重新整合一次

例如：

ChatGPT ── File
        ├─ Git
        ├─ SQLite
        └─ API

Claude ─── File
        ├─ Git
        ├─ SQLite
        └─ API

當 AI 越來越多、Tool 也越來越多，這種整合方式很快就會變得難以維護，所以我們需要一個共同的規則。

MCP 就出現了

MCP 全名是：

Model Context Protocol

MCP 是一套讓 AI Application 與外部工具、資料和服務溝通的協定。

可以先把它想成：

             AI
              │
             MCP
              │
       ┌──────┼──────┐
       ▼      ▼      ▼
     File    Git    Database

AI 不需要為每一個工具都發明一套新的溝通方式，工具也可以按照 MCP 的規則，把自己的能力提供給 AI，這就是 MCP 最核心的概念。就像早期每款手機、相機、耳機都有自己的專用充電孔，AI 應用程式想要連接 GitHub 或資料庫，開發者就得為每個平台單獨弄一條專用轉接線，現在有了 MCP，就只要大家都改用 Type-C（MCP Protocol），工具廠商做一個 Type-C 插頭（MCP Server），不論是 Claude Desktop、Cursor 還是其他 AI 軟體，只要插上去就能直接使用。

MCP 不是 AI，也不是 Agent

這裡有個重點，MCP 本身是不會思考的，它不是一個 LLM ，更不是一個 AI Agent，你可以把 MCP 想成中間的「溝通協定」，真正負責思考的是 AI，而負責執行工作的是 Tool，MCP 負責讓兩邊可以用一套標準方式溝通，所以不要把他們搞混了。

總結

今天只需要記住一句話：

MCP 是一套讓 AI Application 可以用標準方式連接外部 Tools、資料與服務的協定。

先知道這個最基本的定義，之後我們才能繼續下去，而明天我們再來看看它跟我們以前熟悉的 API、Function Calling 到底差在哪裡。